로그인 기능
NOTE
로그인 기능 구현 시 다뤄야 할 흐름(로그인 → 검증 → 실패 처리)과 세션/쿠키·JWT·Spring Security 등 주의할 포인트를 정리한다.
실행 환경
버전 명시 없음 — Spring Security, 세션/쿠키 등 표준 API 개념만 다루어 특정 버전은 확정하기 어렵다.
📌 개념
- 로그인 구현 흐름
- 로그인하기
- 로그인 검증하기
- 로그인 실패 처리
로그인 검증과 실패 처리를 별도 단계로 나누는 이유는, 인증 성공 여부에 따라 이후 처리(세션 생성 후 정상 화면 이동 vs 오류 메시지 노출)가 완전히 달라지기 때문이다.
- 주의해야 할 점
- 세션 처리
- 쿠키와 세션의 차이점
- 세션 처리
쿠키는 값 자체가 클라이언트에 저장되어 개발자 도구 등으로 위조될 위험이 있는 반면, 세션은 실제 값을 서버에 저장하고 클라이언트에는 세션 ID만 전달하므로 더 안전하다. 그래서 로그인 상태처럼 민감한 정보는 쿠키에 직접 담기보다 세션 방식을 쓰는 것이 일반적이다.
- JWT
- Spring Security
- 쿠키 처리 방법
- 쿠키 + 세션 처리 방법
세션 방식은 서버가 사용자 상태를 직접 들고 있어야 해서 서버를 여러 대로 확장할 때 세션 공유 문제가 생기는 반면, JWT는 필요한 정보를 토큰 자체에 담아 서버가 상태를 보관하지 않아도 되므로(Stateless) 수평 확장에 유리하다. 다만 토큰이 탈취되면 만료 전까지 강제로 무효화하기 어렵다는 트레이드오프가 있다. Spring Security는 세션이든 JWT든 이런 인증/인가 로직을 직접 구현하지 않고 표준화된 필터 체인에 위임할 수 있게 해주는 프레임워크다.
- FilterChainProxy
- filter 체인에서 중요한 역할
FilterChainProxy가 중요한 이유는, Spring Security의 인증·인가·CSRF 방어 등 보안 필터들이 서블릿 Filter 체인 위에서 이 프록시를 거쳐 순서대로 실행되기 때문이다. 즉 Spring Security의 인증/인가 로직이 실제로 동작하는 지점이 바로 FilterChainProxy다.
🔗 참고
관련 문서
- (Spring) 로그인 구현 - 핵심 개념 및 특징 정리 — 쿠키/세션 기반 로그인 유지 및 필터·인터셉터 구현 사례
- (Spring) 소셜로그인 전 과정 - 핵심 개념 및 특징 정리 — Spring Security 기반 소셜로그인 구현 사례
- (Spring) Strategy+Factory로 다중 Provider 처리하기 - 핵심 개념 및 특징 정리 — JWT·Spring Security 기반 로그인 인증 구조를 다루는 실무 사례
- (학습/프로젝트/토이프로젝트/게시판 프로젝트) [기능구현#3] 로그인 기능 — JWT vs Session 트레이드오프를 실전 프로젝트 관점에서 다룬 사례